I am still getting people reading this article nearly two years after writing it - which is awesome! But unfortunately, a lot of what is in this article is out of date.
I wrote a new version of this post updated for 2021. It can be found here --> https://dev.to/jameesy/gatsby-vs-next-js-in-2021-what-why-and-when-2fae
Ok firstly, I digress, I am a massive fan of both of these "frameworks". I can usually be seen gushing about them on my Twitter or Instagram, however, without a doubt, the question I get asked the most when talking about these tools is which is better?
Should I use Next.JS? But I have heard Gatsby is pretty 🔥, maybe I should use that?
So I thought I would discuss it a bit further in-depth and hopefully make the choice a little bit clearer.
LETS FIGHT!
Gatsby & Next - An Introduction
So what are Gatsby and Next other than buzzwords you have heard mentioned before but never really understood?
To put it in the most basic terms, in the same way, create-react-app will create you a boilerplate of a React project, these two frameworks will lay the foundations for you to create an application.
They have separated away from create-react-app however, in the sense that they are not classed as boilerplates, but toolkits, laying the foundations and then giving you a set of instructions on how to build the house as well.
To summarise:
create-react-app - Lays the foundations of a React Project. The rest is up to you.
Gatsby & Next - Lay the foundations of a React Project. Give you guidelines on how you should build on top of them.
...
But huh? That's strange? They both do... the same thing?
Sort of.
At first glance, they both look very similar in the sense they both:
- Provide a boilerplate application.
- Generate incredibly performant, accessible and SEO friendly websites.
- Create Single Page Applications out-of-the-box.
- Have a really awesome developer experience.
But actually, they are fundamentally different.
Server Side Rendered vs Statically Generated
Ok, so we start to get a little bit technical here, so stay with me... It's not too bad!
Gatsby is a static site generator tool. A static site generator generates static HTML on build time. It doesn’t use a server.
Next.JS is mainly a tool for server-side rendered pages. It dynamically generates the HTML every time a new request comes in with the use of a server.
Of course, both can call APIs client side. The fundamental difference is Next requires a server to be able to run. Gatsby can function without any server at all.
Gatsby just generates pure HTML/CSS/JS at build time, whereas Next creates HTML/CSS/JS at run time. So each time a new request comes in, it creates a new HTML page from the server.
I'm not going to go too deep into the pro's and cons of each here, however for some more in-depth reading check out this post - https://dev.to/stereobooster/server-side-rendering-or-ssr-what-is-it-for-and-when-to-use-it-2cpg
Data Handling
Another fundamental difference between the tools is the way in which they handle data.
Gatsby tells you how you should handle data in your app.
Next leaves the decision entirely up to you.
What does that even mean?
Gatsby uses something called GraphQL. GraphQL is a query language and if you’re familiar with SQL, it works in a very similar way. Using a special syntax, you describe the data you want in your component and then that data is given to you.
Gatsby makes that data available in the browser when needed by your components.
An example:
import React from "react"
import { graphql } from "gatsby"
export default ({ data }) => (
<div>
<h1>About {data.site.siteMetadata.title}</h1>
<p>We're a very cool website you should return to often.</p>
</div>
)
export const query = graphql`
query {
site {
siteMetadata {
title
}
}
}
`
In the above example, you can see that we have a query to fetch title and then display title within the component. Awesome!
Gatsby also has lots of plugins for various data sources which (in theory) makes it easy to integrate against many data sources. Some examples of data sources plugins are Contentful, Wordpress, MongoDB and Forestry. This allows you to do things such as hook your site up to a CMS and have external control of the content.
When building for production, GraphQL is no longer used, but the data is persisted into JSON files instead.
... Ok cool.
Next on the other hand, how you manage your data is completely up to you. You have to decide on your own architecture how to manage data.
The benefit of that is that you aren't tied into any tech that you may or may not want to be using.
So what should I choose?
Whether you should use Gatsby or Next depends very much on your use case, as really they are both awesome.
When To Use Next.JS
If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages are not the best solution for you. The reason is that it takes much time to build the site if you have lots of content.
When creating a very large app with thousands of pages it can be fairly slow to rebuild. And if you have to wait for a chunk of time when you hit publish before it goes live it’s not a perfect solution.
So if you have a site with content that you will expect to grow and grow over time, then Next.JS is the best choice for you.
Also, if you want more freedom with how you access your data, Next.JS is worth a shout.
It's worth mentioning here that the documentation for Next is some of the best I have ever come across. It has an interactive introduction that quizzes you as you go through the content to make sure you are following along :) awesome! 👏
When to Use Gatsby
I tend to, and this is my personal preference, use Gatsby when I am building small-scale websites and blogs. The eco-system is perfect for hooking up to a CMS (it is literally a breeze) and there are some awesome guides on how to get going with it all.
It is (in my mind) easier to get up and running with Gatsby, so that is worth keeping in mind. Again, the documentation is to a really high level, packed full of tutorials for you to follow along.
Gatsby also comes with some "starter" templates, as well as a relatively recently introduced "themes" which all make getting a fully functioning web app up and running a quick process.
Top comments (71)
One thing I do wan't to mention (that sadly the article does not reflect)
Is the fact you can actually export your NextJS application as a static rendered app.
nextjs.org/features/static-exporting
And the documentation does also reflect this.
nextjs.org/docs#static-html-export
There are some limitations but generally you can copy just the dist folder and you have the app statically generated :)
(though there is some more to it, but it is not that hard, and pretty much reflects the same process as Gatsby)
sadly but true, after exported, dynamic routing like [somewhat].js path will not be working out-of-the-box :(
Hi @stackoverprof
Are you meaning that [somewhat].js is not working?
You have to precalculate the routes (or rather the possible outcomes of the route) for it to be exporting the specific pages - this is particularly done if the fallback is set to false:
nextjs.org/docs/basic-features/dat...
It will return a 404 (naturally) unless you specify the pages for export:
nextjs.org/docs/basic-features/dat...
If however you want to have some paths statically generated and then dynamically generate the rest (think a large ecommerce site, or blog/dynamic pages on a otherwise statically generated site) - you can use the fallback: true (as it will fallback to data fetching)
See this for more info:
nextjs.org/docs/basic-features/dat...
Thankyou
This is honestly the best article I've ever read on Gatsby vs Next.js. Thank you for your contribution!
That means a lot. Thank you, my friend 🙏
I started to learn JavaScript a few days ago and I keep hearing about these frameworks, the most common one I keep hearing about repeatedly is React.
Is there any framework that can make my "learning JavaScript" life easier from the start, and then also pay off later or should choosing a framework wait until I've properly learned JavaScript on its own?
Don't focus on frameworks, first master vanillaJS, there're thousands of resources out there such as YDKJS by Kyle Simpson or Eloquent JS or flavio copes JS handbook. I suggest buying Traversy Media course on udemy of vanillaJS, after that continue with react then the backend, NODE + Express
Once you got the grasp of 1 framework the rest are the same, IMO they're always trying to reinvent the wheel...
PS:forgot about testing, after Frontend and Backend make projects WITH TESTS, i vouch for jest... in today's market this is a must
Hm partially agree, but not completely ... sure, VanillaJS is an important foundation to master, but if you then want to get good at React (and for good reasons, e.g. because the job market for React devs is huge and booming), well that's a whole new different world, you'll again have to climb a big mountain ...
The basics of React are simple but when you reach the stage where you need to know all of these prototypical 'patterns' (HOCs, render props, hooks, context, suspend, and so on), and when to use Redux (and when not), with all of its countless variations (thunks, sagas, whatnot) and 'best practices' ... welcome to a brave new world - React, simple to learn, difficult to master :-)
I just want to make the point that, yes, VanillaJS is important, but A Knowledgeable JS Programmer does not automatically A React Guru make ... it requires substantial extra effort.
VanillaJS can replace most frameworks for building reactive static sites. If you get to master it, no need to learn React to make a simple site.
It is very important to learn the foundations.Once you master the foundation , you can switch to whatever the frameworks for your projects !
Go for vanilla, learn how to manipulate the dom, why jQuery is redundant, learn ES6, array/object methods. Then learn framework that is up to date and people are hiring for knowing it. Frameworks are like cars, everyone argues that certain brand is the best but learning to drive is what matters .
I'm now wondering what the most in-demand (from a hiring / salary perspective) framework is. My goal is to learn enough to get hired but I also want to ensure I have the best salary prospects at the same time. My initial thinking was that "full stack" development must surely be in the highest demand but now I'm thinking it might be smarter to really specialize in pure JavaScript and just one framework.
TL;DR : strategy I followed = cover basics + interview questions, get a job, learn rest on the go. Choice is yours tho.
I was a php dev 1 year before. Took a break for 4 months, learnt basics of JS, Node and Vue, got hired for a reactjs position! Now I'm a full stack dev (react and rails!).
I may not be crazy good these (which is very difficult to become, especially in highly volatile js ecosystem), but brave enough to believe I can make things working with any of these tech. Personally I felt learning speed is much faster when there are deadlines and while working on projects that matters.
I'll highly recommend to follow twitter accounts of devs like dan abramov, where you can get lot of relevant info. Being up to date is critical to survive in JS world IMO. I also follows some sub reddits for webdev, js, react etc. YouTube tutorials of traversy media, academind and net ninja helped me a lot in the initial days.
So these are specifically React-based frameworks. A framework for a framework shall we say ;)
I would stick doing what you are doing for now - check out javascript30.com - when you get comfortable hacking together little projects then, by all means, check out a framework. I think actually it can make the process easier, but I wouldn't recommend doing so before learning the JS fundamentals.
I personally would try and become an expert in vanilla JavaScript... es5 & es6+. Then learn how to serve it up with Node.js and Express. Then learn about webpack and Babel! 😃😃 It will help you understand moving parts of JavaScript and eventually you should learn React.js library . (not a framework) and then Redux. 👍
This is the same problem I had. Whats the point of learning React/gatsby for making sites when you can make reactive static sites with vanillaJs that behave exactly like a native app. This will allow you to master javascript and a do the same that a react app does. Still theres cases where you might want to use React, but it’s overkill for a simple site/blog.
Hmm but isn't the point of something like Gatsby to have you up and running with a blog in a manner of minutes? Who wants to spend all that time setting up each time, the boiler plate can be overwhelming.
I suppose the question is: do you want to master JS or do you want to turn ideas into reality? Its a touch tight rope to balance and it depends on what kind of engineer you are how you are employed (eg solo/contractor/full time).
Please dont do that mistake, dont go with hype, try vanilla js especially the es6 and beyond syntax find out why u need to switch to react, angular, etc. If u dive in now, nothing will make sense at all and you will be in a complete mess
James, thank you! Most of us all the time say that NextJS fits big projects and GatsbyJS is for small. Nobody says why. You pointed out a really important thing: "...content to grow a lot over time, then static generated web pages are not the best solution for you". Basically, it's a truth. A truth that lives now. GatsbyJS community claimed to improve this long time ago and looks like the core team did few steps forward (Read on my blog: webman.pro/blog/is-gatsbyjs-great-...).
What if GatsbyJS team will implement incremental builds support? Can they fight NextJS in context of big application? IMHO, depends, because NextJS
and dynamic SSR will still be more flexible. Let's say your GatsbyJS application based on some global configuration and any change will require rebuilding anyway. What if you had 1 million pages? You would still have to rebuilt all of them with GatsbyJS, right? In case of NextJS you have to invalidate cache only (if you have such). For sure, cost of NextJS infrastructure is a bit higher, but we are not talking about money here :D.
I first came across gatsby and tryied to convert a wordpress site by its API the question is that it have more than 9000 articles (its not the vegeta's joke) it has not even builded. Them I found next.js and it solved the problem, now I'm build a institucional site with a little blog posts system and gatsby are doing the job perfectly
very nice article :D
How long is the build and deploy processing time? Have you try or compare it with Hugo?
Would you recommend Gatsby or Next for a blog with the expectation to scale to 300 or 400 posts over the next one to two years? I'm developing a new website now that already has around 130 and takes about 5 minutes to build on Gatsby.
My personal instinct would be to go with Next.
If you still want to pre-build larger websites, site generators like Hugo and Nift still have surprisingly good build times on websites with thousands of pages or just lots of content. You can use React with at least Nift as well.
I have working on Next.JS project and I hate it.
Annoying routing. Annoying deploying.
And I really don't understand what is the difference between dynamic and static on this context.
You said, "If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages are not the best solution for you."
It means that Next JS generate static web page when 5 school page when data from API just have 5 school data, and when data from API increased to 100 school Next JS generate static web for 100 school?
Plus, annoying deploying.
I have VPS with apache (only. my nginx is crashed) and it's SUPER difficult to deploy Next.JS project. So I am forced to 'static export' the project.
Tried out Gatsby recently, it's really awesome, hoping to go into next.js soon.
From the authors explanation that next.js involves generation of content from the server. In terms of performance making round trips to such server and getting our content would have to affect the speed of such application. I think that was why client side rendering (CSR) was introduced in the first instance.
Well unless we introduce some caching, but still our app would still be slower initially.
I guess we have some pros and cons.
Not necessarily. Rendering on the server-side has the benefit of less back and forth between the client and server as requests have to be made to bring content, so it could actually be potentially faster.
And as you mentioned, server-side rendering makes caching and working with CDNs a lot easier.
Next can now both of the things. I started using Next.js. Never looked back.
In Nextjs
export const getStaticProps = async () => { // getStaticProps for SSG, getServerSideProps for SSR
const data = await fetchData();
return {
props: data,
};
};
IN GATSBY
export const query = graphql
query {
site {
siteMetadata {
title
}
}
}
Rest of the codes are almost same.